Currently, in a conventional solution of testing the compatibility of a 3D engine, for example, in step S102 to step S114 shown in FIG. 1, generally, different graphics cards are selected to perform hardware testing, to determine whether a graphics card to be tested is compatible with a 3D engine. In such a testing method, different models of graphics cards need to be searched for, and a large number of hardware testing environments need to be built for testing; and then information about a tested problem is fed back for development and repair. However, such a solution of testing the compatibility of a 3D engine has many defects:
1. There are some difficulties for building a hardware environment because some graphics cards are difficult to be found, and a large amount of hardware leads to high costs; as a result, the building of a large number of hardware testing environments is difficult to implement.
2. A testing period is relatively long. A client with memory of several GBs needs a relatively long time when copying, inserting and removing a graphics card, reinstalling a driver, and configuring a network environment, which is also inappropriate to a quick procedure.
3. Generally, information fed back by a compatibility test usually only describes a phenomenon (such as a screenshot or a testing environment), helps little in locating a reason, and is also inconvenient for building a testing environment in the terms of development, finally leading to some long-time insolvable compatibility issues.
For the foregoing problems, no effective solution is provided yet currently.